home *** CD-ROM | disk | FTP | other *** search
-
-
- CURRENT_MEETING_REPORT_
-
-
-
- Reported by Jon Saperia/DEC
-
- DECNETIV Minutes
-
- At our meeting in Boulder we discussed/agreed on the following items:
-
-
- 1. The general wording regarding a group's STATUS will be, for
- example; The implementation of the Network Management Group is
- mandatory for all systems which implement session layer
- communications. For those groups which are required for all
- systems regardless; we will use the standard wording - The
- implementation of the Routing Layer Group is mandatory for all
- systems.
-
- 2. Using the approach described above, we discussed the following
- groups and agreed as follows:
- System Group - Required if Session Layer is iplemented Network
- Managment Group - Required if Session Layer is implemented End
- Communications Layer Group - Required if Session Layer is
- implemented
-
- o Routing Group - Required
- o Circuit Group - Required
- o Adjacency Group - Required
-
- There are other groups that we did not discuss and will be proposed
- as Required unless they clearly do not make sense.
-
- 3. Chuck Davin asked if we could work with people developing an X.25
- MIB to see if our X.25 section could be moved out. Chris will
- investigate this. If we can still effectively manage a decnet
- system with this change then we will move the X.25 section out.
-
- 4. The phivExecPhysAddr object will be moved to the circuit group.
-
- 5. All variables which use decnet versions such as the Management
- version will be treated not as sequences of INTEGERs but as
- DisplayStrings.
-
- 6. All enumerated types will not start with 0, they will start with 1
- and a comment will be made in the DESCRIPTION field of each object
- when this change has been made.
-
- 7. The phivSessionExecAddr object will be moved to the routing group.
-
-
- 1
-
-
-
-
-
-
- 8. The Session Layer group will be combined with the Systems Group.
-
- 9. Several objects need to be put into tables, this will be done
- before we put the next revision out.
-
- 10. The object phivRouteMaxArea will be moved to the area group.
-
- 11. The SubAddr objects currently in the Routing group will be moved to
- the X.25 group.
-
- 12. The phivCircuitCommonType object will be modified to look like:
-
-
-
- 2
-
-
-
-
-
-
- phivCircuitCommonType OBJECT-TYPE
- SYNTAX INTEGER {
- DDCMP POINT (0)
- DDCMP CONTROL (1)
- DDCMP TRIBUTARY (2)
- X25 (3)
- DDCMP DMC (4)
- Ethernet (6)
- CI (7)
- QP2 DTE20 (8)
- BISYNC (9)
- FDDI (15)
- }
- ACCESS read-only
- STATUS mandatory
- DEFINITION
- "Represents the type of the circuit. For X.25 circuits, the
- value must be set to X25. For DDCMP and Ethernet circuits it
- is read only and is the same value as the protocol of
- the associated line."
- ::= { circuit 5 }
-
- 13. The follwing objects will be moved to the adjacency group:
- phivCircuitExecAdjacentNodeName
- phivCircuitExecAdjacentNodeAddr
- 14. The phivLineCounterTimer object will be deleted.
- 15. The phivLineDevice object will now be a DisplayString and the
- Communication DEVICE mnemonics section of the DESCRIPTION will be
- deleted.
- Nick will look through the level 1 routing information to see if
- this is required for end systems.
-
-
- We did not have time to cover all items, but a great deal was
- accomplished. Our current goal is to have a draft we feel comfortable
- putting in the drafts directory by the end of January.
-
- Attendees
-
- Chris Chiotasso chris@roswell.spartacus.com
- Anthony Chung anthony@hls.com
- James (Chuck) Davin jrd@ptt.lcs.mit.edu
- Steven Hunter hunter@es.net
- Nik Langrind nik@shiva.com
- Peter Lin lin@eng.vitalink.com
- Oscar Newkerk newkerk@decwet.enet.dec.com
- David Perkins dave_perkins@3com.com
- Kary Robertson
- Jon Saperia saperia@tcpjon.enet.dec.com
-
-
-
- 3
-